Systems and methods for time variable financial authentication

ABSTRACT

The systems and methods of the invention provide a technique for authenticating a finance related transaction. The method may include providing a token which contains a token counter, the token counter periodically advancing to generate a changing token value, the token counter being synchronized to a base counter that generates an authenticating value; transforming the token value into a token output sequence using logic; and outputting at least part of the token output sequence to an authenticating authority, the authenticating authority having access to the authenticating value. Further, the method includes the authenticating authority verifying the validity of the transaction based on the token output sequence and the authenticating value, from which the authenticating authority obtains a verification sequence using the logic, the verifying the validity including the authenticating authority comparing the token output sequence to the verification sequence to determine if there is a match between the token output sequence and the verification sequence.

This application is a continuation-in-part application (CIP) of U.S.application Ser. No. 10/105,471 filed Mar. 25, 2002, which isincorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates to systems and methods to performauthentication of a transaction between a requesting entity, inparticular a customer, and an authenticating authority.

Since the ancient invention of money, problems of counterfeiting haveexisted. These problems have led to ever more sophisticated measures tomake the injection of false tokens, representing value, fromsuccessfully being used in a transaction. When in much more recent timescredit cards were introduced, such measures were incorporated. Forexample, in earlier times, only a check digit formed by a secretalgorithm was used to validate card numbers, the number space being verysparsely occupied so that the chance of finding a valid card number wasrelatively low. Then thieves learned how to forge this digit. As aresult secret cryptography-based codes were added to the cards andchecked by the card issuer when charges to an account were made. Thesemeasures have been useful in reducing fraud until recently.

However, with the practice of merchants storing card numbers, includingsome of the codes, insecurely on the Internet, there have been enoughthefts of these numbers so that fraud is becoming an increasinglydifficult problem. Such fraud often occurs in cases where the cards arenot physically present. Fraud is reduced somewhat where the card isphysically present. That is, credit cards contain fraud avoidancedevices like holograms which make counterfeiting of physical cards moredifficult than counterfeiting numbers off the cards.

Further, rules designed to prohibit storing the secret codes have beenignored, even by large issuers and as a result a new way to preventfraudulent card use for remote customers is becoming necessary. Smartcards using public key encryption have been introduced, but these havemet with little acceptance, due to their need for gadgetry to read them,which is not widely available.

Known techniques in the area of time based codes reach back to ancienttimes, when the password of the day was common in military camps. Thenotion of using widely synchronized times to control functions dates atleast to the philosophy of Gottfried Liebniz (coinventor of the calculusand a contemporary of Isaac Newton). During World War II, codebooksvalid for a particular day were used by both sides. The use of timestamps in computer communication is almost as old as computing. Anexample of their use in authentication can be found in the Kerberossystem (MIT, 1987). Financial transactions have been timestamped toavoid replay problems also.

However, known techniques fail to provide an approach to effectively usethe advance of time as an effective authentication mechanism. Thepresent invention addresses the above, as well as other problems, thatare present in known techniques.

BRIEF SUMMARY OF THE INVENTION

The systems and methods of the invention provide a technique forauthenticating a finance related transaction. The method may includeproviding a token which contains a token counter, the token counterperiodically advancing to generate a changing token value, the tokencounter being synchronized to a base counter that generates anauthenticating value; transforming the token value into a token outputsequence using logic; and outputting at least part of the token outputsequence to an authenticating authority, the authenticating authorityhaving access to the authenticating value. Further, the method includesthe authenticating authority verifying the validity of the transactionbased on the token output sequence and the authenticating value, fromwhich the authenticating authority obtains a verification sequence usingthe logic, the verifying the validity including the authenticatingauthority comparing the token output sequence to the verificationsequence to determine if there is a match between the token outputsequence and the verification sequence.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can be more fully understood by reading thefollowing detailed description together with the accompanying drawings,in which like reference indicators are used to designate like elements,and in which:

FIG. 1 is a diagram showing a token in accordance with one embodiment ofthe invention;

FIG. 2 is a block diagram showing a processing system in accordance withone embodiment of the invention;

FIG. 3 is a block diagram showing an authenticating authority inaccordance with one embodiment of the invention;

FIG. 4 is a flowchart showing a “customer initiates transaction” processin accordance with one embodiment of the invention;

FIG. 5 is a flowchart showing the “perform authentication process” inaccordance with one embodiment of the invention;

FIG. 6 is a flowchart showing the “perform verification process on thetransaction” step of FIG. 5 in accordance with one embodiment of theinvention;

FIG. 7 is a flowchart showing the “calculate ‘verification sequence’based on device number and time of transaction” process of FIG. 6 inaccordance with one embodiment of the invention;

FIG. 8 is a flowchart showing the “perform alternative processing tofurther process authorization” step of FIG. 6 in accordance with oneembodiment of the invention;

FIG. 9 is a diagram showing a token in a flashlight in accordance withone embodiment of the invention; and

FIG. 10 is a block diagram showing a token using a twenty-four hourclock in accordance with one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Hereinafter, features in accordance with various embodiments of theinvention will be described. As used herein, any term in the singularmay be interpreted to be in the plural, and alternatively, any term inthe plural may be interpreted to be in the singular.

The present invention supplies a display on a consumer device, inaccordance with one embodiment of the invention. The display displays anauthentication code that varies with time. The “time” is synchronized toa known base time. An authenticating authority, such as the issuer forcredit cards for example, can determine whether the correct code isbeing sent to it for a particular consumer device and for a particulartransaction time. The time variability is obscured by a secret processon the consumer device to prevent those not in possession of the secretprocess from figuring out the code sequence. As a result, theauthenticating authority can decide whether the requested transactioncomes from a valid source. Because the display number is variable, itcannot be recorded on the Internet or elsewhere in a form useful fortheft, save for very limited durations. Further such recorded numberscannot be used to aid in impersonating a holder of a consumer device,e.g., a credit card, for purposes of identity theft. Widespread use ofthis invention will make telephone, network, or other remote commercesafer for all involved.

The token, in accordance with one embodiment of the invention, may beissued by an authenticating authority. An “authenticating authority” asused herein means either a central authority or a distributed authority,for example. The authenticating authority is capable of deciding whetherto authorize transactions where a token is provided as a way to checkthe validity of authorizations, i.e., to permit them. The authenticatingauthority possesses authority to perform transactions in the scope ofthe invention including authority to effect a payment or authorize someother financial or financial-related transaction

In accordance with one embodiment of the invention, the invention useswhat might be characterized as a token. The token is used to indicateauthority to perform transactions. The token includes a token clock ortoken counter that can maintain synchronization with a reference clock,i.e., a base counter, during the lifetime of the token. Thissynchronization might be maintained to within one or a few times theinterval between changes of identifier. In accordance with oneembodiment of the invention, this might include a counter which “ticks”,i.e., changes value, one or a few times per day, for example.

Further, the token also includes a device or mechanism for performing asecret transform on the clock value. In accordance with one embodimentof the invention, this transformation might also involve some otherseparately observable attribute of the token, such as the credit cardnumber or a cellular phone number. The token uses the secret transform,which is not available to the token holder, but that is reproducible byan authenticating authority. Further, the secret may be different forevery such token so that if one is lost, only its secret is lost andother tokens remain secure. The result of this transform, or part of theresult of the transform, is displayed by the token in such a way thatthe displayed number can be read by a person or device, i.e., whatevermight read the token, and transmitted to an authenticating authority.Optionally, such an authority might demand that additional memorizeddigits or some other identifying indicia be supplied. This other indiciawould further preclude use of a stolen token. That is, the token asdescribed herein may be used with any other known authenticationtechnique, as desired.

In accordance with one embodiment of the invention, the invention may bein the form so as to resemble a credit card. In addition to the existingcredit card fields, i.e., such as magnetic stripe, for example, the cardin accordance with one embodiment of the invention is provided with asmall processor and battery. Further, the card includes a display thatis visible on the card. The display shows a few digits computed by asecret process on the card. One such implementation might take a secretmaster key known to the issuer and encrypt the card account number andexpiration with this master key. This diversified key then gets storedon the card. Further, it is noted that the diversified key may bedifferent for each card.

As noted above, a clock computes a value that is transformed and thendisplayed on the token. That is, the token first reads the clock. Theclock may be in the form of a counter of some type. For example, theclock for a certain batch of credit cards might advance based on the“hours since midnight on Jan. 1, 2001”. Further, the credit cards mightbe synchronized when issued. In accordance with one embodiment of theinvention, the initial value generated by the clock is encrypted withthe diversified key.

Further, only the low three decimal digits of the result are displayedon the display, for example, in accordance with one embodiment of theinvention. Of course, it is appreciated that any number of digits orselection of digits may be used, as is desired. Physically, theinvention will not pose a problem since there currently exists flexiblenumeric displays much thinner than credit cards. Should power be limitedto drive such a display all the time for a few years, a pushbutton orother switch might be present to conserve power.

When the credit card holder of the token of the invention makes a phonepurchase or a net purchase, for example, he or she then reads thedisplay, and possibly recites some other digits she is given to retainor memorize, in accordance with one embodiment of the invention. Forexample, such other digits might be the fixed CVV code (card validationvalue) on the back of the credit card. The credit card holder thenfurnishes such information to a merchant. The merchant then sends theinformation to the issuer, or some other authenticating authority, forvalidation.

The authenticating authority receives the card number, timestamp of thetransaction, the token value and any added data. The authenticatingauthority then derives the diversified key from the card number and themaster secret the particular card holds and/or reads such informationfrom storage. Further, the authenticating authority checks the timestampsupplied for sanity, i.e., performs a crude reasonableness test, anduses the timestamp to derive the expected on-card clock value. Theauthenticating authority then encrypts this clock value with thediversified key and compares with the value supplied by the customer.

So as to avoid clock drift problems, the authenticating authority maycompare adjacent timeslot values for the comparison operation. Theauthenticating authority then treats these adjacent timeslot values asmatches if one of them produces the same code as was reported. The exactnumber of these comparisons depends on expected maximum clock drift oncard over the card lifetime, i.e., two to three years, for example, andmay be varied as desired. For example if it is expected the clock mightdrift under an hour, and the clock changes value at midnight, thentransactions after 11 PM might be compared also with the next day'scode, and similarly transactions before 1 AM might be compared with theprior day's code. In this way the card user never sees any effects ofthe clock changing during his transaction.

In accordance with further aspects of the invention, as noted above, avariety of other values may be supplied to a token holder for use inauthenticating transactions. These other values can be recorded by theauthenticating authority, or alternatively, can be computed by such anoperation as encrypting the card number with a second secret key andusing part of such resulting number. This additional number is enteredwhen making a transaction, along with the displayed number, by thecardholder. Such added information makes a token less useful to someonewho stole the token, as they would have to guess the correct checkdigits or digits to fool the authenticating authority.

Further, it may be desirable for the values, which the token displays,to be related mathematically to some separate observable about thetoken, e.g., such as a cellular phone number. For example, a secondidentifier built into the token may be used mathematically forcomputation of the value displayed by the display on the token. Fortokens of the nature of credit cards, the preferred implementationencrypts the card number. For tokens like cell phones, there is a phoneID number which could be used. Such practice would make it harder toforge tokens and will be found to be of particular use for tokens inwhich the internal state cannot be hidden well from users, i.e., theinternal state meaning a cell phone number, for example. In those caseswhere the internal state cannot be hidden, it may be desired to useother identifiers, in addition to the token value described herein, inorder to gain the added protection against fraud.

As described herein, one embodiment of the invention uses a tokenresembling a credit card. However, any of a wide variety of tokens maybe used. Accordingly, as used herein a “token” means a device which ispresented or which bears information which is presented by someone toset up a payment or similarly authorize some financial orfinancial-related transaction. Accordingly, a token of the invention maybe in a wide variety of forms including a token in the form of a creditcard, or a gasoline-buying “speedpass,” for example. Accordingly, thetoken in the invention may be in the form of credit card or debit cardtype device possessing a display to be read by the cardholder, a creditcard type device having a magnetic strip, a radio frequency generatingdevice, an infrared signal generating device, an audio signal generatingdevice, a magnetic pattern generating device, and/or other devices foroutputting a data signal, i.e., such as a PDA (personal digitalassistance) outputting a data signal to a computer or to a cashier, forexample.

Further, as described herein, the token of the invention generates a“display.” As used herein, a “display” means whatever sends informationoff the token for authentication checks. For credit card type tokens,the display might be some visible display. For other types of tokens,the display might be a radio or audio signal, or magnetic patterns, forexample. Accordingly, a “display” in a token of the invention mayillustratively be an LED (light emitting diode), an LCD (liquid crystaldisplay), a magnetic strip, a radio frequency signal, an infraredsignal, an audio signal, a magnetic pattern, any other data signal, orany other technique that may be used to convey information from thetoken to the merchant, and in turn to the authenticating authority, forexample. As is appreciated, interim steps may be needed such as a humancardholder reading the token output sequence and inputting the tokenoutput sequence into a computer via a keyboard or to a human merchantverbally, for example.

As described in various examples herein, the token of the invention maybe used in an interaction between a customer and a merchant. However,the token of the invention may be used in a variety of other situationsbetween any of a wide variety of entities. For example, the treasurer ofa corporation might use the token described herein to validateinstructions to a bank, i.e., regarding a desired transaction, forexample. Accordingly, the token of the invention might be used inconjunction with transactions between two banks or between any otherinstitutions or entities, for example.

The checking is preferably done off the token, although a centralauthority's processing might be replaced in some cases by somecombination of other processing with perhaps other tokens whose trust isestablished in other ways, e.g., such as biometrics, for example, toallow local checking of such tokens for authenticity. That is, the tokenof the invention may well be used in conjunction with otherauthentication checks, such as simply a credit card number, for example;and the authenticating authority may be made up of separate portions soas to collectively perform the verification process.

Hereinafter, further aspects of the systems and methods of the inventionwill be described with reference to the drawings. FIG. 1 is a diagramshowing a token 100 in accordance with one embodiment of the invention.As shown in FIG. 1, the token 100 includes a device number 110. Whilethe token 100 is shown in FIG. 1 as being similar to a credit card, itis appreciated that the token 100 may be in any of a wide variety ofshapes and sizes.

As shown in FIG. 1, the token 100 also includes a magnetic strip 120.Further, the token 100 includes a token output sequence 130, i.e., anumber, that is presented by a display 132. The token output sequence130 is generated by the token 100 based on the progression of a clock,as described above, for example. In order to conserve energy of thetoken 100, the token output sequence 130 might not be displayed at alltimes. That is, the holder of the token 100, in accordance with oneembodiment of the invention, presses the power display button 140 todisplay the token output sequence 130. Such action results in a tokenoutput sequence being displayed and visible to the holder. As shown inFIG. 1, the token 100 may also include a signature panel 150 to providefurther verification of the veracity of the holder.

To explain further, the token output sequence 130 is generated using atoken counter 160. The token counter 160 generates a token value. Thistoken value is output within a token 100 to an encryption portion 170.The encryption portion 170 provides logic to process the token value toresult in the token output sequence 130. Both the progression of thetoken counter 160 as well as the logic used in the encryption portion170 is known and simulated by a verification or authenticating authorityso as to verify a transaction by the holder of the token 100.

The embodiment of FIG. 1 utilizes a display 132 to display the tokenoutput sequence 130. However, is appreciated that the token outputsequence 130 may be displayed using a variety of techniques, as isfurther described below. For example, the token output sequence 130might be input into the magnetic strip 120, i.e., so as to be output toa merchant, for example.

FIG. 2 is a block diagram showing a processing system 10 in accordancewith one embodiment of the invention. As shown in FIG. 2, the processingsystem 10 includes a customer token 100. Further, the processing system10 includes a merchant entity 200 and an authenticating authority 300.

In accordance with one embodiment of the invention, the customer token100 takes the form of the device shown in FIG. 1. Further, the merchantentity 200 may be in any of a wide variety of forms such as merchantdisposed in a physical merchant store, an internet entity, a receiversuch as on a toll road device, a telephone entity, as well as a widevariety of other arrangements, as should be appreciated. Further, asshown in FIG. 2, the token 100 may be disposed in a variety of devices,such as in a flashlight, key chain, cellular phone, a personal digitalassistant, and/or a watch, for example.

FIG. 3 is a block diagram showing in further detail the authenticatingauthority 300. The authenticating authority 300 includes a generalprocessing portion 310 and a general memory portion 320. The generalprocessing portion 310 controls overall operations of the variouscomponents disposed in the authenticating authority 300. Further, thegeneral memory portion 320 provides a wide variety of memory resourcesto the authenticating authority 300.

The authenticating authority 300 further includes an input portion 330.The input portion 330 inputs information necessary to verify atransaction performed using the token 100. Illustratively, the inputportion 330 inputs a device number from a token, the time thetransaction, as well as a token output sequence. The authenticatingauthority 300 further includes a base counter 350. The base counter 350outputs an authenticating value based on the transaction time, which isreceived from the token 100. This authenticating value is created usingprocessing performed in parallel to the token counter 160. Specifically,the base counter 350 simulates the output that the token counter 160would have generated at the time of the transaction.

Further, the authenticating authority 300 includes an encryption portion360. The encryption portion 360 calculates a verification sequence inthe same secret logic as in the token 100. In the authenticatingauthority 300, the encryption portion 360 operates in conjunction withthe secret logic memory portion 370 to generate the verificationsequence. For example, the secret logic memory portion might use thedevice number to determine which logic to apply to the verificationsequence, e.g., using a look-up table, for example.

In accordance with one embodiment of the invention, it is noted that thelogic might use the device number in mathematical processing of theauthenticating value, or, in the token, the logic might use the devicenumber in mathematical processing of the token value.

Further, the authenticating authority 300 includes a comparison portion380. The comparison portion 380 uses the verification sequence, which isgenerated within the authenticating authority 300, and compares suchverification sequence with the input “token output sequence,” which isinput from the token 100.

FIG. 4 is a flow chart showing a customer process in accordance with oneembodiment of the invention. As shown in FIG. 4, the process starts instep 500 in which the customer initiates a transaction. After step 500,the process passes to step 510. In step 510, the customer reads, or insome other manner conveys, the device number to the merchant. Then, instep 520, with reference to the embodiment of the invention shown inFIG. 1, the customer presses the power display button. As a result, thetoken output sequence is displayed for viewing by the customer.Accordingly, in step 530, the customer reads the token output sequenceto the merchant. In conjunction with step 530, the customer device,i.e., the token 100, for example, calculates the token output sequencebased on a token value generated in the token, i.e., based on theprogression of the clock in the token. After step 530 of FIG. 4, theprocess passes to step 540. In step 540, the customer input to thetransaction is completed.

FIG. 5 is a flow chart showing an authenticating authority process inaccordance with one embodiment of the invention. As shown in FIG. 5, theprocess starts in step 600 and passes to step 610. In step 610, theauthenticating authority obtains the device number from the customer.Then, in step 620, the authenticating authority obtains the token outputsequence number from the customer. After 620, the process passes to step630. In step 630, the authenticating authority also inputs the time ofthe transaction, i.e., which may be obtained from the merchant inaccordance with one embodiment of the invention. Accordingly, each ofthe items of information input in steps 610, 620 and 630 are obtainedfrom the customer and/or the merchant and may typically be transmittedfrom the customer through the merchant so as to be input by theauthenticating authority.

Returning to FIG. 5, after step 630, the process passes to step 640. Instep 640, the authenticating authority performs a verification processon the transaction. FIG. 6 is a flowchart showing in further detail step640. After step 640 of FIG. 5, the process passes to step 800. In step800, the verification process is completed.

As noted above, FIG. 6 is a flowchart showing in further detail the“perform verification process on the transaction.” As shown in FIG. 6,the process starts in step 640 and passes to step 650. In step 650, theprocess, i.e., performed by the authenticating authority, calculates a“verification sequence” based on the device number and the time oftransaction, which has been input. Then, in step 660, the authenticatingauthority compares the “token output sequence” input from the customerwith the “verification sequence”. After step 650, the process passes tostep 670.

In step 670, as shown in FIG. 6, the process determines whether thetoken output sequence that is input from the customer matches with theverification sequence that is generated within the authenticatingauthority. If yes, i.e., there is a match, then the process passes tostep 672. In step 672, the transaction is authorized. After step 672,the process passes to step 699.

Alternatively, it may be the situation that in step 670, the tokenoutput sequence does not match with the verification sequence. As aresult, the processes passes from step 670 to step 680. In step 680, aninitial determination is made that the transaction is not authorized.However, this is merely an initial determination. That is, after step680, the process passes to step 690. In step 690, the process performsalternative processing to further consider the authorization. That is,the process performs further processing to ascertain whether thetransaction was indeed a valid transaction. FIG. 8 is a flowchartshowing in further detail step 690. After 690 of FIG. 6, the processpasses to step 699

In step 699, the process may perform a supplemental transactionvalidation, as is necessary or desired. That is, it is appreciated thatthere may be other criteria that makes an authenticator decide to allowthe transaction or not. For example suppose a transaction is comingsupposedly from Seattle and the authenticating authority experienced atransaction, with the same token, from New York 10 minutes ago. Theauthenticating authority might want to decline this transaction even ifthe authorization number appeared to be correct. Likewise even if thetransaction is not authorized, maybe the issuer will determine theelectronics have glitched and he may use other information, ask themerchant for other information, or just warn the merchant and let themerchant decide whether to go ahead anyway, i.e., since the merchantwill bear any loss. After step 699, the process passes to step 700. Instep 700, the process returns to step 800 of FIG. 5.

FIG. 7 is a flowchart showing in further detail step 650 of FIG. 6“calculate verification sequence based on device number and time oftransaction.” After the sub-process of FIG. 7 starts, the process passesfrom step 650 to step 652. In step 652, the process determines the“authenticating value” based on the time of transaction. Then, in step654, the process determines the “secret logic” based on the devicenumber. That is, it is appreciated that different logics may be used fordifferent devices. The device number, or some other identifying indiciathat may be associated with a particular device, may be used todetermine which logic should be applied by the authenticating authority.After step 654, the process passes to step 656. In step 656, the processproceeds with applying the secret logic to the “authenticating value” todetermine, in turn, the “verification sequence”. After step 656, theprocess passes to step 658. In step 658, the process returns to step 660of FIG. 6.

FIG. 8 is a flowchart showing in further detail the “perform alternativeprocessing to further process authorization” step 690 of FIG. 6. Inparticular, the process of FIG. 8 relates to the situation where clockdrift has occurred between the clock in the authenticating authority ascompared with the clock in the token 100. Such drift between the clocksmay result in an initial finding that a transaction is not valid.However, the process of FIG. 8 addresses a potential incorrect findingof an invalid transaction.

To explain, the process of FIG. 8 starts in step 690 and passes to step692. In step 692, the process determines whether the time of transactionis near the beginning of a clock interval, i.e., is the time of thetransaction near the time that the clock in the authenticating authorityexperienced a change. If yes in step 692, then the process passes tostep 693. In step 693, the process recalculates the verificationsequence based on the previous base counter setting. After step 693, theprocess passes to step 697.

Alternatively, in step 692, the process may have determined that thetime of the transaction is not at the beginning of a clock interval. Asa result, the process passes to step 694. In step 694, the process, asillustratively performed by the authenticating authority, determineswhether the time of the transaction is near the end of a clock interval.If yes, then the process passes from step 694 to step 695. In step 695,the process recalculates the “verification sequence” based on the nextbase counter setting. Then, the process passes to step 697.

In step 697, the process determines whether the token output sequenceinput by the customer matches with the recalculated verificationsequence. That is, step 697 checks whether the previous or the nextclock setting of step 693 and step 695, respectively, result in a matchbetween the token output sequence and the verification sequence. If yes,then the process passes to step 698. That is, if there is indeed a matchthen the transaction is authorized. After step 698, the process passesto step 698′. Alternatively, in step 697, there may still not be a matchbetween the token output sequence input by the customer and therecalculated verification sequence. As a result, the process passes tostep 697′ and the transaction is not authorized. After step 697′, theprocess passes to step 698′.

As noted above, in step 694 of FIG. 8, the process determines whetherthe time of the transaction is near the end of a clock interval.Further, step 692 determined if the transaction is near the beginning ofa clock interval. If neither of the situations is present, then theprocess passes to step 696. In step 696, the process determines that thetransaction is indeed not authorized. As a result, the process passes tostep 698′. However, it is appreciated that more then the immediatelyadjacent intervals may be considered. For example if the clock advancesrelatively quickly, this results in a potential for substantial clockdrift. As a result, it may be desired to check three, for example, (oras many as desired) intervals before the initially considered interval,as well as three subsequent intervals, for example.

In step 698′, the process returns to step 699 and then to step 700 ofFIG. 6. As noted above, in step 700 of FIG. 6, the process returns tostep 800 of FIG. 5 in which the verification process is terminated.

In accordance with a further embodiment of the invention, FIG. 9 is adiagram showing a token 100′ disposed in a flashlight 700. The token100′ may operate in a similar manner to the token 100, as shown inFIG. 1. The flashlight 700 may include batteries 702. In accordance withone embodiment of the invention, the batteries 702 may power operationsof the token 100′. As described above, the token 100′ generates a tokenoutput sequence, and transmits the token output sequence to a merchant200. This transmission may be in a variety of forms, as is shown in FIG.9. In turn, the merchant 200 outputs the token output sequence, as wellas a time stamp and a token device number, which is also obtained fromthe token, to the authenticating entity 300.

In accordance with a yet further embodiment of the invention, FIG. 10 isa block diagram showing a token 800 that may operate in a similar mannerto the token 100. The token 800 includes an encryption portion 870 and adisplay 880. The encryption portion 870 provides the logic to convertthe token value into the token output sequence, as described above. Thislogic may take on a variety of forms so as to manipulate the tokenvalue, as is desired, i.e., such as a mathematical manipulation of thetoken value, for example. The token counter of the embodiment of FIG. 10includes a clock 862 and a tick reduction portion 864. The clock may bea standard twenty-four hour clock, but may preferably be a digitalclock, i.e., such that a digital output may be output to the tickreduction portion 864.

The tick reduction portion 864 works off the advancement of the clock862 to generate the token values. However, the tick reduction portion864 advances at a much slower rate. For example, for every 12 hours thatthe clock 862 advances, the tick reduction portion 864 may only advanceonce. As is noted above, such reduced advancement reduces the effects ofclock drift between the token and the authenticating authority.

In accordance with further aspects of the invention, it is appreciatedthat the token value, the token output sequence, the authenticatingvalue, and the verification sequence, for example, may be numbers,letters, symbols, punctuation and/or any other character set, forexample. However, the particular composition of the token value, as wellas the corresponding authenticating value, should be such that suchvalues may advance in a routine manner.

As described above, the systems and methods of the invention rely upontime stamping in accordance with embodiments of the invention.Accordingly, a variety of techniques may be used to address differenttime zones. For example, one time zone may be designated as a standardand all time stamps converted to this standard.

As described above, methods and systems are disclosed which permittokens used for finance to be checked for authenticity by having thetokens display an authentication code that varies with time, yet can bevalidated by the token validation authority. Because the authenticationcode changes, such codes may not readily be stored and stolen, as is aproblem in existing codes. The invention reduces fraud for all involvedwhere there is risk that a token might be a forgery.

It will be readily understood by those persons skilled in the art thatthe present invention is susceptible to broad utility and application.Many embodiments and adaptations of the present invention other thanthose herein described, as well as many variations, modifications andequivalent arrangements, will be apparent from or reasonably suggestedby the present invention and foregoing description thereof withoutdeparting from the substance or scope of the invention.

Accordingly, while the present invention has been described here indetail in relation to its exemplary embodiments, it is to be understoodthat this disclosure is only illustrative and exemplary of the presentinvention and is made to provide an enabling disclosure of theinvention. Accordingly, the foregoing disclosure is not intended to beconstrued or to limit the present invention or otherwise to exclude anyother such embodiments, adaptations, variations, modifications andequivalent arrangements.

1-29. (canceled)
 30. A system comprising: a credit card providing adynamically generated number for authenticating a financial transaction;and a device for reading the dynamically generated number from thecredit card and transmitting the dynamically generated number to anauthenticating authority for authenticating the financial transaction.31. The system of claim 30, further comprising: a token counter, thetoken counter periodically advancing to generate a changing token value,the token counter being synchronized to a base counter that generates anauthenticating value, wherein the dynamically generated number is basedat least in part on the token value.
 32. The system of claim 30, furthercomprising communicating the dynamically generated number wirelessly tothe device.
 33. The system of claim 30, further comprising communicatingthe dynamically generated number to the device via a magnetic stripe ofthe credit card.
 34. The system of claim 30, wherein the credit cardcomprises a battery.
 35. The system of claim 30, wherein the credit cardcomprises a processor for providing the dynamically generated number.36. The system of claim 30, wherein the dynamically generated numbercomprises at least a portion of a credit card number.
 37. The system ofclaim 30, wherein the dynamically generated number comprises anauthentication code
 38. The system of claim 30, wherein the credit cardcomprises a clock, the clock used to enable generation of thedynamically generated number.
 39. The system of claim 38, wherein theclock is synchronized with a clock of the authenticating authority. 40.The system of claim 30, wherein the credit card further comprises amanual switch.
 41. A method comprising: providing on a payment card adynamically generated number; displaying on a display of the paymentcard the dynamically generated number; and a device for reading thedynamically generated number from the credit card and transmitting thedynamically generated number to an authenticating authority forauthenticating a transaction.
 42. A machine readable medium, executableby a machine, that includes program logic imprinted thereon forperforming the method comprising: providing on a payment card adynamically generated number; displaying on a display of the paymentcard the dynamically generated number; and a device for reading thedynamically generated number from the credit card and transmitting thedynamically generated number to an authenticating authority forauthenticating a transaction.